1. Field of the Invention
The present invention generally relates to controlling the execution of actions on a computer system, and more specifically relates to a method, system, and computer program product for limiting authorization of an executable action to an application session.
2. Related Art
Lotus Notes includes an Execution Control List (ECL) that allows users to control what code can be executed on a user's computer system based on who signed the code. The ECL enables users to protect their data and computer systems against viruses, Trojan horses, and other malicious code. The ECL provides a mechanism for managing whether such code should be allowed to execute and what level of access the code should be permitted. The ECL uses digital signatures to verify executable code. When an attempt is made to execute a piece of code, Lotus Notes verifies the digital signature on the code and then looks for the user's ECL settings to determine whether the action can be executed or whether the user should be prompted. If the signer of the code is found in the user's ECL (either explicitly as part of an organization) and the appropriate capability is enabled, the code is executed seamlessly. If the signer's name is not found in the ECL or is found but the capability is not selected, the user is prompted with an Execution Security Alert dialog box showing the action to be performed, who it was signed by (and how the signature was verified), and the capability that is not allowed with the current ECL settings. An example of an Execution Security Alert dialog box 10 is illustrated in FIG. 1. As shown, the Execution Security Alert dialog box 10 is configured to prompt a user for which option to take in response to the alert. The options include:    (1) “Do NOT execute the action”;    (2) “Execute the action this one time”; and    (3) “Start trusting the signer to execute the action” (i.e., add the signer to the user's ECL).
The second option, “Execute the action this one time” is meant to handle the case where the user does not want to trust the signer forever for a particular action, but wants to allow execution of the action this one time. Unfortunately, the Execution Security Alert dialog box 10 may pop up many times if this action occurs repeatedly during the running of a program, requiring the user to select the second option over and over again. When this situations occurs, it is not unusual for the user to simply select option three, thus allowing the program to perform the action at any time in the future. This has the undesirable effect of reducing security on the user's computer system, as the action may be executed at any time in the future without the user being alerted.
Sun Java JAAS (Java Authentication and Authorization Service) provides another model for fine tuning execution control permissions. In this model, a policy file is used to indicate that an entity represented by a principal, executing a specified code, has a designated permission. This is an all or nothing permission model, and the permission is persistent until the policy file is updated. Unfortunately, over time, users will often trade security for more convenience in this type of all or nothing model by always granting permission, thus exposing their computer systems to security threats.
Another model for fine tuning execution control permissions is used mostly in relational databases. This model is very similar to the Sun Java JAAS model. In particular, a user is granted (read, write, delete) permission against some data element in the database. In this model, as in the Sun Java JAAS model, the permission is either all or nothing; either a user has permission until further intervention or the user has no permission.